| Oracle TimesTen In-Memory Databaseアーキテクチャ概要
リリース6.0 B25763-01 |
|
 前へ |
 次へ |
従来のRDBMSでは、クライアント・アプリケーションがなんらかの種類のIPC接続を通じてデータベース・サーバー・プロセスと通信を行います。これにより、すべてのSQL処理に対して、かなりのパフォーマンスのオーバーヘッドが加わります。アプリケーションでは、TimesTenをそのアドレス空間に直接リンクすることにより、IPCオーバーヘッドを排除し、問合せ処理を簡素化できます。これはTimesTenに直接接続することで実現されます。クライアント/サーバー接続も、アプリケーションで有効です。アプリケーションから見ると、直接接続またはクライアント/サーバー接続かにかかわらず、TimesTen APIは同じです。
さらに、従来のディスク最適化RDBMSによって行われる作業の多くは、データが主にディスクに常駐するという仮定のもと行われます。この基本的な仮定に基づいて、最適化アルゴリズム、バッファ・プール管理、および索引検索技法が設計されています。
RDBMSがその全データをメイン・メモリー内に保持する構成である場合でも、ディスク・ベース・データの常駐という根深い仮定がパフォーマンスの足かせになります。これらの仮定は、十数年にわたる研究開発を経て、RDBMS処理ロジック、索引付けスキーム、データ・アクセス・メカニズムなどについて、最深部にハードコードされているため、簡単に変更できません。
一方、TimesTenは、データがメイン・メモリーに常駐するという認識で設計されているため、コードパス長を削減し、アルゴリズムと構造の両方を簡素化して、データへのより直接的な経路を選択できます。
ディスク常駐という仮定がなくなると、複雑さは大幅に緩和されます。マシンのコマンド数は10分の1以下に減少し、バッファ・プール管理や余分なコピーは不要となり、索引ページも縮小し、これらの構造は簡素化されます。データのメモリー常駐が基礎的な仮定であれば、設計はより単純かつ簡潔に縮小され、リクエストは高速に実行されます。
図1.1 ディスク・ベースのRDBMSとTimesTenの比較
